Debugging Pascal
Volume Number: 2
Issue Number: 9
Column Tag: Intermediate Mac'ing
Debugging with LightSpeed Pascal 
By David E. Smith, Editor & Publisher
The Boston Expo this week promises to offer a world of new Mac products of
particular interest to developers. Many of these products will revolutionize how
software is done on the Mac, so it is time to take stock and review the software
development process on the Mac.
Where to Begin
The first step in the product development cycle is to get information. This means
getting a copy of Inside Macintosh by Addison Wesley, volumes 1-3 and soon volume 4. I
prefer the hard bound all in one edition (great for dropping on bugs). Next some Mac
hardware is in order. A Mac Plus with a two meg upgrade from MacMemory is a must. A
hard disk, scsi type, is helpful. The DataFrame 20 has been reported as a "safe" buy,
reliable, few problems. A new round of 60 to 100 meg drives is also appearing in the
$2500 range. Hardware and book in hand, it's time to reach for the check book and buy
additional information. Apple's software supplements and technical notes are a must,
from Apple's mailing facility. For referencing the ROM, there is TOM's Program's
little ROM reference deck. Finally, don't forget the MacTutor subscription!
Utilities are important. No programmer should be without Fedit Plus, Mac Nosy
2.1, TMON or Heap Show. Both Fedit Plus and Mac Nosy 2.1 are new versions being
shown at Boston. All four of these products are available from MacTutor as well as
other technical software outlets. Heap Show is a very valuable little utility that allows
you to analyze heap use in your program, find dangling handles and pointers, and help
you prevent heap fragmentation. It is one of the most valuable of utilities yet is also the
least known.
Now loaded with documentation from IM, supplements and back issues of
MacTutor, the next step is finding out what it all means. For this, the only way to go is to
sign up for Dave Wilson's Macintosh Programming Class. This is Apple's official
introduction to Mac Programming and it is indispensible. I just finished the class and I
really learned a lot about the Mac that I either didn't know or didn't understand
correctly. Dave is a master teacher and well versed in the Mac hacker's world. Cost is
not cheap at $1,000, but it's well worth the price if your part of a company project.
Six months after you're well along in development, thanks to Dave Wilson, you can then
sign up for Scott Kanaster's Mac College to get the bugs out of your project. But we're
getting ahead of ourselves. First you must decide on a development system.
HFS Changes Development Environment
Under MFS, the Mac supported a number of traditional development systems. The
Aztec C 1.06G is preferred by Unix programmers because it preserves much of the
Unix flavor of software development within the Mac interface. Consulair C and TML
Pascal both present a similar Mac User Interface for software development using the
traditional Edit/Compile/Link process. Under MFS, this traditional approach worked
fine. However, under HFS, this approach breaks down because development systems
must devise various methods of finding include files and trap files now arranged in
different directories. The real problem is that HFS really makes the traditional
approach of edit, compile and link obsolete. It simply takes too much time to run a
program, bomb a program, debug a program, edit, compile, link and try again, when
dealing with such a highly interactive and dynamic environment as Macintosh. Servant
may ease this problem when available, by bringing a user configurable integrated
environment to seperate programs not originally designed to be integrated, making a
kind of user constructable LightSpeed environment, with the added advantage that you
select the tools to install.
Solving the HFS Problem
The new world of development systems now coming out for the Mac solve the HFS
problem by creating a development environment, in which all the files necessary to
support the program development cycle is known to the system. These new systems are
MPW from Apple, which brings Object Pascal and MacApp in a strong Unix style
environment with scripts; TML Pascal 2.0, which also supports Object Pascal and
units; and the newest product, LightSpeed C & Pascal, which create a "Project" that
bundles files together dramatically speeding up compile and link. Let's focus on
LightSpeed Pascal as this product typlifies the new "environment" approach that the
Mac interface encourages.
Integrated Tools Speeds Debugging
Mac programming is primarily a process of "discovering" what the Mac ROMS
will let you do and how they let you do it. Because of this, re-running programs over
and over to experiment is a primary debugging task. With traditional edit, compile and
link systems, this process takes several minutes. Make five change and test cycles and
you've used up the better part of an hour! With the concept of a "Project", all files are
loaded and available, compilation is virtually instant as only the necessary compilation
is done, everything else is pre-compiled. Finally, linking is automatic since the
project knows both what to link, and what needs to be re-linked after a change. The
editing and executing environment are the same, so you can both edit, and execute your
program from the same shell, switching back and forth with a click of the mouse
between your program's window and menus, and LightSpeed Pascal's windows and
menus. Source is always available for editing and source code debugging is fully
supported. The result is faster turn-around time in the edit, compile, execute, bomb,
re-edit cycle. Instead of several minutes, new attempts are created and tested in
seconds. An interactive environment that produces fully compiled double-clickable
applications, DA's and drivers.
How it works
The key to LightSpeed Pascal is the project concept. A project is a window and a
file that contains a list of all filenames associated with a particular program effort. It
also contains compiler and linker information that allows only changed code to be
re-compiled and linked dynamically. Since libraries and include files don't have to be
re-loaded and compiled as they do on traditional systems, the project approach makes
fast turn-around of the compile and link process.
We write a program within our project environment with the LightSpeed Pascal
" system". This system includes a multi-file editor. Our editing window is always
available, even while our program is running. A build command creates a final
application for us that is a fully compiled stand alone program we can move to any disk.
For MDS ".REL" files, we can convert them to our project library format with a
converter utility, provided. The compiler is fully Lisa and TML Pascal compatible. We
compiled last month's keyboard sleuth program without any problem. The system does
not have an assembler, so assembly code still must be assembled using MDS or
Consulair C systems, and then converted for loading into our project.
The Debugging Process
If your frustrated at trying to marry your development system with MacsBug
and TMON, then you'll really appreciate the LightsBug debugging window. Debugging is
the key to this system. The system automatically debugs your source code as you type,
checking for syntax errors on entry. Instant compilation checks again for normal
compilation errors. Finally, running the program again checks for run-time errors. At
any time, if an error occurs, you can change the source, look at the debugger window,
try some parameter values in the observe window, or change variable values in the
instant window. To see what your program is doing, modify the source, set breakpoints
and run again. Watch your window while you also watch the debug window! The debug
window is automatically linked to the point where your program stopped, showing the
heap trail, register values and your global variables. A single click on a global
variable, and bang! The debugger shows you a hex and ascii memory dump at the location
of the variable.
Figure 1 shows the many windows of LightSpeed Pascal. Our own program
window is also available! The project window lists our library, source and include files.
Compiler options are set for each file by clicking in the box next to the file name. We
change the link order for our project by simply dragging the file name up or down in
the project window. No more editing of a link file!
Our source code is shown in another window, and we can open a window for each
of our source segments. The observe window allows us to monitor the value of a
variable as our program executes. The Instant window allows us to execute program
source code or trap calls instantly to observe their effects. If we get what we want, we
can paste the line into our source window. Text and drawing have the same purpose they
did under MacPascal, but even more important, our own toolbox created windows from
our running program are available and clickable along with each of the other windows
shown in figure 1.
In figure 2, we see how the observe window works. Here, we've placed a
breakpoint at the putstring(s) statement in the source window. After running, our
program is now stopped at the break, and the value of s is shown in bold in the observe
window. Note that in the LightsBug window, we instantly have the base address of the
variable s and can observe it's value in both hex and ascii.
In figure 3, we now change the value of s in the instant window. As we do this, the
observe window shows the new value of S, and the LightsBug window shows the new hex
and ascii values for s in memory.
In figure 5, we now wish to change the value that is assigned to s directly in
memory where our source code lives. We do this by clicking edit and another little debug
dialog box opens allowing us to enter a new value directly into memory. As we do this,
the LightsBug window shows that what used to be " there!" is now "fere!". This also
changes our source code and when we run the program, as figure 6 shows, the new
source code value is shown being assigned to s during execution.
Figure 7 shows that our program window exists along with LightSpeed Pascal's
windows and we can swtich back and forth by clicking on the spray can (for debugging!).
Finally a Decent Manual
For some reason, Mac development systems have shipped with manuals that
assume you already know every language command by heart. Very few even have a
simple language definition. If you don't already know C or Pascal, forget it! The
LightSpeed manuals are very well done, very large and provide a clear description of
the language syntax and commands much like normal manuals on other computers have
traditionally done. It is a mystery to me why it has taken this long for decent manuals
to be shipped with Mac development environments.
Reaction
I personally think these products will revolutionize how software is done on the
Mac. The time saved in testing and re-running programs under development is so
tremendous that no one will settle for the large development time required of
traditional edit, compile, and link systems. The Mac takes more time anyway in the
learning curve of the ROM functions, so anything we can gain in the development cycle
is extremely important. But most of all, LightSpeed Pascal will be very popular
because no one will want to live without source level debugging with LightsBug if they
don't have to. The debugging capabilities will cause people to stop and think if they
really need all the overhead of MPW after all.